Two commonly deployed technologies for delivering television service are cable and satellite. Cable television typically utilizes a coaxial cable as the physical medium on which television signals are broadcast. Individual television channels can be selected for viewing via a set-top box or “cable-ready” television. Satellite television utilizes satellite dishes which are aligned with satellites to receive wireless broadcast signals. Like cable, individual television channels are selected via a set-top box. Because of the relatively high cost of deploying cable and satellite infrastructure, the barriers to entry for potential competing television service providers are high.
An infrastructure which already exists and has potential for delivery of television services is the telephone network. For example, it has been proposed to provide television service via Digital Subscriber Line (“DSL”) technology. However, DSL lacks the bandwidth necessary to broadcast hundreds of television channels simultaneously to a set-top box on a local loop. It has been proposed to only transmit the individual currently selected television channels to subscribers so as to operate within the bandwidth available on the local loop. This approach is sometimes called Switched Digital Broadcast because the user controls a switch in the network that selects from all television channels the channel (or potentially 2 or 3 channels) that are delivered on the DSL loop to the residence. Switched Digital Broadcast requires that the delivery network support a control protocol to signal the user's choice of television channel to be delivered to his/her set-top box (the channel change protocol (“CCP”)) and a data plane mechanism for replicating the data streams that are the selected television channels onto every set-top box that has selected them. It has been commonly proposed for DSL delivered SDB transport that each TV channel is a distinct Internet Protocol (“IP”) multicast group (i.e. with its own IP multicast address) and then to use a version of the Internet Group Management Protocol (“IGMP”) as the CCP, and matching this to use (“IP”) multicast routers for replicating data streams, following the rules of IP multicast forwarding. However, this solution requires IGMP snooping capability in all WLAN and Ethernet switches in the residence up to the channel change point. It also requires that the access network implement full IP protocol stacks and is dependent on whether IP version 4 (IPv4) or IP version 6 (IPv6) is in use (for IPv6 deployments the Multicast Listener Discovery (“MLD”) Protocol replaces IGMP). Further, since the CCP is an in-band control protocol it fails to provide support for a policy server to block or modify channel selections.
Some of the short comings described above were addressed in the ISO/IEC standard 13818-6 Digital Storage Media-Command and Control (DSM-CC), which defined a CCP specifically for SDB. The DSM-CC SDB CCP is a application level protocol between a client (such as a set-top box) and an SDB Server. The SDB server is not required to be the network element that replicates the television channel data streams, so there is the opportunity for the network to apply per subscriber policies to channel change operations. Further, the SDB-CCP protocol allows the set-top box to be provided with characteristics of the newly chosen channel, such as the codec used in its encoding and any conditional access encryption keys needed to de-encrypt the content. However, one shortcoming of the DSM-CC SDB model is that it assumes that the television stream is delivered over ATM as the layer 2 protocol, and in its own virtual circuit connection (“VCC”). While the usual layer 2 protocol for DSL and metropolitan networks that serve the DSLAMs that drive the DSL loops has been ATM, the usual mode of operation is to use a single VCC per DSL loop. Hence, this single VCC would have to carry all broadband traffic, both point-to-point and broadcast.
U.S. Pat. No. 6,788,696 describes a VC merge mechanism whereby the chosen channel contents can be merged into the point-to-point VCC so that all content going to the residence appears at the DSLAM and on the DSL loop as a single VCC. This single VCC model of operation works best when there is only a single device at the end of the DSL loop, which is not the situation with the so-called “triple play.” With “triple-play” the intention is to deliver Internet access, multimedia telephony and television services to multiple devices in the home. The home requires a network to connect these devices to the DSL loop termination point and this network is most often an Ethernet compatible network (i.e. Ethernet itself, Wireless LAN or something like phone net). Further, network operators have signaled a desire to move away from ATM as the layer 2 protocol in their metropolitan aggregation networks and use Ethernet technology instead. Ethernet in itself is a connectionless layer 2 protocol and there have been several standards efforts initiated to replicate the virtual circuit mechanism when the underlying transport mechanism is not ATM. In effect, the goal is to replace ATM VCCs with Ethernet pseudo wires. Ethernet pseudo wires are realized by pre-pending customer Ethernet packets with a virtual circuit label and then encapsulating the result in to some (service) provider packet transport frame. When the virtual circuit label is an MPLS label and the provider packet transport is MPLS this encapsulation is often called “Martini encapsulation” after the author of the first Internet Draft document that described it. The IETF working group that originated the term “pseudo wire” has so far considered only two types of provider packet transport: MPLS and IP. However it has been noted in another Internet Draft, called “Dry Martini,” that pseudo wires do not depend on the label being an MPLS format label, nor on the provider packet transport protocol being MPLS or IP. Although not explicitly labeled as a being a pseudo wire realization, the MAC in MAC protocol, or, as it is now called, Provider Backbone Bridging (PBB) being standardized by the IEEE 802.3ah group is a form of pseudo wire: the label field is a the Service Tag and the provider packet transport is Ethernet. The original intent of pseudo wires is that they behave just as a real wire would in terms of transporting customers packets, i.e., a pseudo wire provides a point-to-point connection service where packets accepted at one end are delivered unchanged, and in the same order, at the other end. Thus to deliver both unicast and broadcast traffic to a DSL loop over a single pseudo-wire would require that both types of traffic be merged together as a single Ethernet packet stream before the (downstream) ingress point of the pseudo wire. Typically this ingress point is deep inside the metropolitan aggregation network and in some deployments it is actually in another metropolitan network altogether. This is problematic because performing the switching function, replicating broadcast packets, at the PE end point would be very inefficient as perhaps 10 s of thousands of copies of the same TV channel stream of packets would have to be transported over the same network link.